When an incident is received (from any source), it must be reviewed to validate if it is within the scope of Incident Management process. For example: In case a user reports an incident, which is a service request, the Request Fulfillment process must be initiated. User credentials must also be cross checked.

If the incident is within scope, a record for the same must be created in the IT Service Management tool. Accurate information should be captured to enable resolver team to circumvent or resolve the incident. Typically, the information would include:

• Unique reference number, generated automatically
• User’s name and his contact details
• Incident description
• Submitters’ actions
• Impact of incident on business (numbers of Users impacted)
• Error messages
• Cross reference to event record (if applicable)
• Relation to existing incident (if any)
• Urgency and priority
• Date/time of every update, from logging to closure
• Name of who logged and updated the incident
• Method of notification (telephone, automatic, email, in person, etc.)
• Symptoms, questions asked by the service desk, and the answers given by the user
• Steps taken to try to resolve the incident (successful or otherwise) 
• Incident status
• Related CI/problem/known error 
• Assignee group and individual
• Closure category, etc.

Incidents must be categorized based on domain, application groups, service, configuration items, etc. Incident prioritization is done to ensure that the most critical incidents are dealt with, first. Business impact and urgency (how quickly the business needs a resolution) are two factors to be considered for deciding priority. Business impact can be assessed by considering a number of factors: the number of people affected, the criticality of the service, the financial loss being incurred, damage to reputation, and so on. In case the priority is given by client or user, the same must be reviewed.

Incident category and priority can be revisited at later stages as well.